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Abstract 


This memo introduces a domain and supplier independent generic 
architecture for information brokerage, designed as part of the ACTS 
project GAIA (Generic Architecture for Information Availability). 


1. Introduction 


Today a huge number of goods and services are offered on the 
electronic market by a large, and ever-increasing, number of 
suppliers. However, there is still no efficient way for a customer 
to find a product or information, he/she is interested in and a 
supplier that can provide that product. Customers and suppliers 
already can not deal with the quantity of available information by 
themselves. The high heterogeneity of existing protocols, formats, 
and underlying networks also limits development of the electronic 
market. 


This results in a demand for brokerage systems that can work as 
intermediary entities between customers and content suppliers. 
Brokerage systems assist a customer during the trading process and 
hide the heterogeneity and distribution of information from the 
customer. The design of domain and supplier independent generic 
architecture for such brokerage systems is an objective of the 
project GAIA (Generic Architecture for Information Availability). 
GAIA received part funding from the EU ACTS programme for Research 
and Technological Development. The GAIA brokerage system allows a 
customer to 
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- search for a particular "product" (information, content or 
services) that he/she is interested in 

- locate the product, i.e. find supplier(s) from whom the product is 
available 

- order the product from the supplier 

— receive delivery of the product by digital means 


All these actions are carried out by the broker in response to 
requests from the customer. Broker services are accessible to the 


customer through the unified user interface. The customer system 
does not have to support all the protocols involved in the trading 
process. 


Full specification of the GAIA Architecture is available in the GAIA 
Standard [1]. The GAIA Standard includes a description of the GAIA 
Reference Model, GAIA Functional Architecture, GAIA Standard 
Profiles, and specification of the GAIA interfaces. 


This memo does not aim to include the whole text of the GAIA 
Standard, but to present the basic ideas and concepts of this 
standard. 


The structure of this memo follows the structure of the GAIA 
Standard: 


1. The GAIA Reference Model provides a common basis for the 
description and specification of brokerage systems, including the 
GAIA system. 


2. The GAIA Functional Architecture defines functional elements of 
the GAIA Broker, their roles and relationships. 


3. The GAIA Brokerage System Interfaces describes internal and 
external interfaces of the GAIA brokerage system. 


4. The GAIA Standard Profiles specifies mandatory and optional 
profiles to which brokerage systems may conform. 


2. The GAIA Reference Model 


The Generic Architecture for Information Availability (GAIA) 
Reference Model outlines the operations and actors involved in 
finding, ordering, and delivering physical and digital objects and 
services ("Products") in a global brokered distributed information 
environment. It provides an overall view of the GAIA environment, 
and illustrates the respective roles of and relationships between its 
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components. Further work on standards and frameworks for individual 
components of the GAIA environment uses the model and terminology 
provided by the Reference Model. 


The GAIA environment is a collection of actors and functions that are 
combined to support a procedure for information and services 
discovery, order, and delivery. The actors play roles in the 
procedure, including initiation and execution of the Actions which 
are combined to make up the overall transaction. The GAIA 
architecture provides a standardised and widely applicable framework 
for the provision and implementation of the brokered search and 
retrieve applications in a large-scale networked environment. 


GAIA Roles 


The GAIA model considers three principal roles that can be played by 
the GAIA actors. These are the Customer, the Broker and the 
Supplier. These Roles are shown in Figure 1 below. It also 
considers a further class of active entities who play supporting 
roles in the Actions. This latter class is known as GAIA "Helpers" 
and includes, for example, authentication and payment. The actors 
are organisations and individuals in the supply chain. Every GAIA 
actor plays at least one role at any given time. 


1. The Customer 


The aim of the Customer is to obtain some Products or information 
about some Products. The Customer role initiates the GAIA 
transaction by requesting one or more GAIA Actions, and receives the 
results of the transaction. The Customer may deal with actors 
playing either of the other two roles: the Broker or the Supplier. 
These actors may themselves play the role of the Customer while 
requesting further services from other Brokers. 


-2. The Broker 


The Broker provides brokerage services to the Customer and the 
Supplier. It responds to requests from the Customer to provide 
Products, or information about Products. The Products that the 
Broker supplies to the Customer may originate from one or more 
Suppliers and/or Brokers. The Broker’s primary role is to act as a 
collector and collator of information from a number of different 
Suppliers, and to supply this information to the Customer, thus 
obviating the need for the Customer to deal with a variety of 
Suppliers. A Broker can also be considered to act on behalf of a 
Supplier, distributing information about the Products available. The 
actor playing the role of the Broker may play the role of a Supplier 
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to a Customer or other Broker at the same time. The Broker may play 
the role of a Customer while interacting with another Broker or with 
a Supplier. 


2.1.3. The Supplier 


The Supplier is the source of the Product supplied to the Customer. 
The Supplier provides the Broker with information about the Product 
that it can supply. The Supplier may supply its Product directly to 
the Customer, or to the Broker for forwarding to the Customer. An 
actor playing the role of a Supplier may also play the role of a 
Broker. A Supplier may deal with a large number of Brokers and 
Customers over a number of GAIA transactions. 


2.1.4. Helpers 


A Helper is an application layer entity playing a supporting role in 
a GAIA transaction. Helpers provide some service needed in the 
supply chain, but outside the core functionality of the Broker. 
Examples include a global directory service, payment service, or 
authentication service. 


The authentication Helper is concerned with facilitating the 
authentication of one actor to another. 


The payment Helper is concerned with supporting a mechanism for 
payment to one actor by another. 


In any given GAIA transaction, there will be one or more Customers 
(usually one), one or more Brokers, and one or more Suppliers. A 
description of the Product sought by the Customer is provided by the 
Customer to the Broker. The Broker may involve other Brokers in the 
search for the Product. When a Supplier of the Product is discovered 
by the Broker, this information is included in the response of the 
Broker to the Customer. During the course of the Action, it may be 
necessary to call upon the services of one or more Helpers. 


2.2. GAIA Actions 


Each GAIA transaction is made up of one or more Actions. These 
Actions are requests by the Customer to the Broker or the Supplier to 
carry out some operation and to return a response. Four Actions are 
defined: 


Search 
- Locate 
—- Order 
— Deliver 
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These Actions are shown in Figure 1. 


+-------- + : ; +-------- + : ; 4+----------- + 
| |-- Search -->| |-- Search -->| |+ 
| ree Grace | 
| |-- Locate -->| |-- Locate -->| | 
|Customer | : f | Broker | : | Supplier (s)| | 
| |-- Order --->| |-- Order --->| | 
<- Deliver == <- Deliver == 
4+-------- + : : +-------- + : : +----------—- +| 
+----------- + 


Helpers Helpers 
<Authentication> <Payment> <Security> 


Figure 1 GAIA Roles and Actions 
2.2.1. Search 


The Search Action is carried out when the Customer asks the Broker to 
find some information on its behalf. To do this, the Customer 
provides the Broker with some description of the Product it requires. 
On the basis of this description, the Broker carries out a search on 
behalf of the Customer and returns the result. The result of a 
Search Action is a set of unique identifiers referencing the Products 
matching the description provided by the Customer. 


2.2.2. Locate 


The Locate Action is carried out when the Customer asks the Broker to 
provide it with information regarding the location and source of some 
Product. To allow the Broker to do this, the Customer provides an 
unambiguous identification of the Product, which may be the result of 
a Search Action. The Broker returns information to the Customer 
about a source or sources for the Product. These data include the 
Terms of Availability information such as available methods of 
delivery, time of delivery, costs, etc. However, this information 
can not be considered final since some special terms and conditions 
may apply, e.g. discounts for some categories of Customers. The 
final version of the Terms of Availability is established during the 
negotiation phase of the Order Action. 


2.2.3. Order 
The Order Action is carried out when the Customer asks the Broker to 
obtain a Product on its behalf, or asks the Supplier to sell the 


Product directly to the Customer. To enable an Order, the Customer 
provides the Broker/Supplier with Product source information, which 
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may be a result of a Locate Action. The Order Action consists of a 
negotiation phase and (possibly) a purchase phase. During the 
negotiation phase the Customer obtains the quotation that contains 
the final version of the Terms of Availability for the (batch of) 
Products he is considering purchasing. If the Customer finds these 
conditions satisfactory, he commits to the purchase. Alternatively, 
if the Broker or Supplier supports telepresence services for the 
human interaction with the Supplier or Broker representatives, these 
may be used during the negotiations. 


2.2.4. Deliver 


The Deliver Action is carried out when the Broker provides the 
Customer with some requested Product. The Product may be 
information, some physical object, or metadata. The Deliver Action 
may be in response to an Order Action, a Search Action, or a Locate 
Action. 


While the Actions presented in this section may logically be taken to 
form an integrated sequence, this is not necessarily the case. 
Actions may take place independently, rather than as a part of a 
four-Action whole. For example, Order and Deliver Actions may occur 
on the basis of information obtained by the Customer using some other 
mechanism than GAIA Search and Locate Actions. 


2.3. GAIA Helper Events 


During any of the GAIA Actions outlined above, it may be necessary to 
carry out some supporting activity. These activities are called GAIA 
Helper events. They include, for example, authentication and 
payment. The Helper entities are involved in the GAIA events to 
provide services, additional to the GAIA Actions, to the GAIA actors. 


Authentication 


In order to verify the identity of one GAIA actor to another, an 
authentication exchange may need to take place. This may occur 
during any of the GAIA Actions. The manner or method of 
authentication is outside the scope of this document. 


Payment 


It may be necessary for payment to take place during a GAIA 
transaction. In this situation, one GAIA actor pays one or more 
other GAIA actors. The manner or method of payment is outside the 
scope of this document. 
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3: 


3: 


Security 


As part of any GAIA Action, it may be necessary to carry out some 
security operations, such as encryption of data, verification of 
source and content integrity of Product, or digital signature of some 
data entity or entities. The particular security services and 
mechanisms which may be required, or the manner in which they may be 
provided, is outside the scope of this document. 


The GAIA Functional Architecture 
1. The Concept 


The GAIA Functional Architecture decomposes the overall functionality 
of the GAIA Broker into a number of components and describes the 
roles and relationships of these components, and the manner in which 
they interoperate. 


To work in a heterogeneous environment the GAIA Functional 
Architecture introduces three levels of abstract elements of the 
Broker: the Kernel, Functional Unit Managers (FUMs), and Functional 
Units (FUs) (see Figure 2). 


[ Kernel ] Kernel 
/ X level 
/ \ 
[Functional Unit] [Functional Unit] Technology-independent 
[ Manager ] [ Manager ] action-dependent 
/ \ / \ level 
/ \ / \ 
[Functional] [Functional] [Functional] [Functional] Technology 
[Unit ] [Unit ] [Unit ] [Unit ] dependent 
level 


Figure 2 Levels of the architecture 


Functional Units are the technology dependent parts of the 
architecture. They perform required transactions in terms of a 
particular protocol. All FUs are covered by a technology independent 
interface. FUs are grouped according to the trading action they 
participate in, e.g. search FUs or locate FUs. Each group of FUs is 
governed by the corresponding Functional Unit Manager. 


Functional Unit Managers contain technology independent functions for 
particular actions. To use a particular technology an FUM uses the 
services of attached FUs. There may be several FUs associated with 
an FUM, allowing the FUM to operate in different technology contexts. 
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There is one FUM in the system for every area of functionality, e.g. 
search, locate, and order. The Kernel is responsible for managing 
the activity of different FUMs (corresponding to different actions) 
and synchronising events between them. 


The GAIA Functional Architecture establishes relationships between 
the existing technologies (standards and protocols) that are combined 
in the GAIA Standard, in the context of a brokerage system. It is to 
be expected that new technologies will evolve which will be viable 
alternatives to those selected. The abstract and modular nature of 
the Functional Architecture allows the replacement of one technology 
with a new one without disruption to the rest of the brokerage 
system. 


3.2. Functional Units 


The brokerage system provides a number of services to its users. 
These services are supported by the functions of the brokerage 
system. These include, for example, 


- searching 
- ordering 
— payment 


Each of these functions can be provided by a number of different 
candidate technologies. However, the operations that are required to 
be carried out remain the same. Regardless of the selected 
technologies, the functional requirements do not change. The 
required operations are described in terms of abstract primitives, 
which can be mapped to the protocol instructions of the technology 
selected to support the function. A mapping component, called a 
Functional Unit (FU), is defined for each candidate technology, and 
converts calls to abstract primitives into protocol instructions. 
The FU acts as an adaptor between its particular technology and the 
rest of the brokerage system. 


Functional Units are defined for each candidate technology that can 
be used to fulfil a particular functional need of the brokerage 
system. A Functional Unit accepts abstract primitive invocations, 
and maps them to calls to the particular technology to which it is 
dedicated. The results of these calls are translated into the 
corresponding abstract primitives and returned by the FU, as shown in 
Figure 3. 
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* The rest of the Broker * 


A 


| -abstract primitives 


v 

+------------ + 

| Functional | 

| Unit | 

4+—------------ + 
| -technology-specific commands 
v 


* Technology functions * 
Figure 3 GAIA Functional Unit 
3.3. Functional Unit Managers 


As noted above, a number of different candidate technologies can be 
used to fulfil a particular functional requirement of the brokerage 
system. Depending on the details of the GAIA transaction (underlying 
network, Customer system capabilities, etc.), different technologies 
may be more useful during different transactions. As a result, each 
candidate technology has its own Functional Unit, which is invoked 
when that particular technology is required. 


A number of different Functional Units can exist which fulfil the 
same functional requirement of the brokerage system. To select the 
most appropriate FU (and technology), the brokerage system needs to 
know which is the most useful at any particular time; in general this 
is the technology supported by the target Supplier system. This is 
the responsibility of the Functional Unit Manager, or FUM. Each 
function of the brokerage system has a single FUM, which is invoked 
using abstract primitives by the Broker Kernel. This FUM selects the 
most appropriate of the candidate technologies, and calls the 
corresponding FU (see Figure 4). 


The interface between the FUM and the corresponding FUs is defined 
for every FUM in an open, platform independent, and programming 
language independent manner. These interfaces do not depend on any 
particular technology. It allows for configuring the set of 
technologies supported by the Broker, by attaching different subsets 
of FUs. If a new technology is to be supported by a Broker, a new FU 
implementing this technology can be created according to the 
specification of the interface, and attached to the corresponding 
FUM. 
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v v 
+------------ + +------------ + 
| Functional | | Functional | 
| Unit | | Unit | 
+------------ + +------------ + 
N N 


| -technology-specific commands- | 


v v 
* Technology * * Technology * 
* functions * * functions * 


Figure 4 Functional Unit Manager 
3.4. The Kernel 


The Kernel of the brokerage system acts as a bus for the transmission 
of abstract primitives between FUMs. Each FUM imports a set of 
abstract primitives representing those services which the FUM expects 
to receive from some other part of the system. The services that the 
FUM is prepared to provide to other elements of the brokerage system 
are presented in the form of exported abstract primitives. All these 
abstract primitives are imported from, and exported to, the Kernel 
(see Figure 5). 


The Kernel is also responsible for synchronisation of different 
actions within a transaction and for maintaining a common context 
between actions. 


+------------------------------------- + 
| Broker Kernel | 
+------------------------------------- + 
| -abstract- | -primitives- | 
v v v 
+------- + +------- + +------- + 
| FUM | | FUM | | FUM | 
+------- + +------- + +------- + 


Figure 5 Broker Kernel 
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3.5. Description of FUMs 


The core activities of the brokerage system include: 


1. searching for Products that fit a user description 

2. sourcing Products the identification of which is known 
3. allowing users to order Products 

4. delivering information in item format 

5. delivering information as a continuous media stream 

6. providing a user interface to the brokerage services 
7. alerting users as to the availability of information 
8. interacting with external directory services 

9. authentication of other actors 

10. payment operations 


Each of these activities is carried out by the corresponding FUM as 
described below and shown in Figure 6. 


Search FUM 


The Search FUM accepts requests to carry out a search for Products 
that fit a particular user description. It returns lists of 
identifiers of Products that fit the description. 


Locate FUM 


The Locate FUM accepts Product identifiers and discovers where they 
may be obtained. It returns lists of Suppliers and locations for the 
Product. 


Order FUM 


The Order FUM manages negotiations between a Customer and a Supplier 
in order that agreement may be reached on the terms of availability 
of a particular Product or group of Products. Following the 
negotiation phase, the Order FUM accepts purchase commitments from 
the Customer and forwards them to the Supplier. It returns a 
notification of the status of the Order Action. 
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The GAIA Broker: 


(Customer) ) (Alerting) ) ( DS )) (Auth) ) (Payment) ) 
( FUs )) ( FUs )) ( FUs )) ( FUs)) ( FUs )) 
(e.g.HTTP) ) (e.g. SMS) ) (eg LDAP) ) ( )) (e.g.SET) ) 

\/ \/ \/ \/ \/ 
[Customer] [Alerting] [ DS ] [ Auth ] [Payment] 
[ FUM ] [ FUM ] [ FUM ] [ FUM ] [ FUM ] 

| | | | 
4+------------------------------------------------ ---- + 
| Broker Kernel | 
4+---------------------------------------------------- + 

| | | | | 
[ Search ] [ Locate ] [ Order ] [ Stream ] [Discrete] 
[ FUM ] [ FUM ] [ FUM ] [Delivery] [Delivery] 
[ ] [ ] [ ] [ FUM ] [ FUM ] 

/\ /\ /\ /\ /\ 
( Search )) ( Locate )) ( Order )) ( SD )) ( DD )) 
( FUs )) ( FUs )) ( FUs )) ( FUs )) ( FUs )) 
(eg 239.50) ) (eg 239.50) ) (eg ISO ILL) ) (eg RTP) ) (eg FTP) ) 


Figure 6 GAIA Functional Architecture 


Discrete Delivery FUM 


The Discrete Delivery FUM manages the delivery of discrete items to 
the Customer. 


Stream Delivery FUM 


The Stream Delivery FUM manages the delivery of real-time multimedia 
data streams to the Customer. 


Customer FUM 


The Customer FUM provides an interface to support the Customer’s 
systems interaction with the brokerage system. 


Alerting FUM 


The Alerting FUM notifies Customers about changes that may interest 
them. 


Directory Services FUM 


The Directory Services FUM provides an interface between an external 
directory service and the brokerage system. 
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Authentication FUM 


The Authentication FUM provides a mechanism that allows a user to 
prove his identity to the brokerage system. 


Payment FUM 


The Payment FUM provides a mechanism for payment from one actor to 
another. 


4. GAIA Brokerage System Interfaces 


This Chapter describes the internal and external interfaces of the 
GAIA brokerage system. 


4.1. Internal Interfaces 


The definition of communication between functional components within 
the GAIA Broker is based on the OMG CORBA model [2]. Interfaces 
between components are defined in the IDL language specified by OMG. 
Interface calls are passed between components by the Object Request 
Broker (ORB). 


The advantage of this approach is that the specifications of the 
interfaces are platform and programming language independent. These 
interfaces can be implemented using different programming languages 
on different platforms. All necessary conversions during interface 
invocations are transparently performed by an ORB. The CORBA model 
also allows installing different functional components of the GAIA 
Broker on different computers connected by a network. Interface 
calls will be transferred over the network by an ORB transparently 
for the application. 


The specification of the interfaces between the Kernel and FUMs and 
between each FUM and corresponding FUs is presented in the GAIA 
Standard [1]. 


4.2. External protocols 


The GAIA Broker can use existing protocols to communicate with other 
actors. For example, it can use HTTP for interactions with 
Customers, 239.50 for search, etc. As described in the GAIA 
Functional Architecture, support for particular technologies is 
provided by FUs. A set of supported protocols can be extended by 
attaching the corresponding new FUs to a Broker. The GAIA Broker can 
support several protocols for each action. The FUMs will select the 
most appropriate protocol for a transaction. The more protocols 
supported by the Broker, the better service it can provide to 
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Customers and Suppliers. 


The GAIA Standard does not limit the set of protocols supported by 
the Broker. However, for the purpose of interoperability, it 
specifies several GAIA profiles. These profiles define a common 
subset of protocols (and a common range of protocol parameters) that 
Brokers are encouraged to support in order to make communication 
between GAIA Brokers, and with GAIA-aware Suppliers and Customers, 
possible. 


Existing protocols are not the only way to contact the GAIA Broker. 
The GAIA interfaces have been designed as a generalisation of 
existing interfaces and protocols, so they provide more functionality 
than any particular protocol. To give access to the full 
functionality of the GAIA Broker, the GAIA Standard allows users 
(Customers and other Brokers) to directly use the CORBA-defined 
Customer interface of the GAIA Broker (interface between the Customer 
FUM and FUs) as shown in Figure 7. In this case, the Customer system 
gets access to the Customer interface of the Broker using the service 
of an underlying ORB, and can request operations by calling the 
corresponding methods of the interface. The Customer interface of 
the GAIA Broker is specified in the GAIA Standard [1]. 


Where Customer and Supplier systems are not CORBA-aware, they can 
communicate with a GAIA Broker using existing protocols. If, 
however, they can use the service of an ORB, they are encouraged to 
communicate with a Broker by connecting to its Customer interface. 
This method allows for avoiding convergence between a particular 
protocol and the GAIA interface. The former method makes 
interactions with all existing types of Customers and Suppliers 
possible using existing and widespread protocols. The later method 
has been designed to achieve maximum functionality by using native 
GAIA methods for communication with Customers and Suppliers. 
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Dis 


5; 


+---------------- + 
|Broker 
e + | [ Kernel ] | 
| Broker | | Rra E | 
| or | | [Customer] | 
| Customer | | [ FUM ] | 
========== <-GAIA Customer 
* ig a | \interface 
| {ORB *}* * * * * * *{* O R B* } | 
+----------—- + iiop | * | +---------- + 
| (Customer) | | Customer | 
| ( FU) | | | 
r I---+ +----JI----- + 
\ HTTP / 


Figure 7 External protocols and the GAIA Customer interface 
GAIA Standard Profiles 


The GAIA Standard defines a number of profiles, which a Broker may 
support in order to achieve interoperability with other GAIA actors 
(Customers, Suppliers and other Brokers). The complexity of the 
profile chosen by a Broker depends on the level and type of service 
which the Broker wishes to deliver in a GAIA-conformant manner. The 
higher the level of service that a Broker provides to a Customer, and 
the greater the length of the supply chain which the Broker wishes to 
support, the more advanced the profile and/or the greater the number 
of extension modules the Broker must support. 


1. Supply Chains 


The GAIA profile definition approach is based on the possible types 
of supply chain that a brokerage system can be a part of. 


The operations of a brokerage system can be broken into three 
categories: 


—- interactions with the Customer 
—- interactions with other Brokers 
- interactions with Suppliers 


The first and last of these occur at the two ends of a supply chain, 
while interbroker operations take place at other points in the chain. 
The supply chain may take a number of different forms: 
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—- a minimal chain, where the Customer and the Broker are the ends of 
the chain and there are no intervening links. In this case, the 
Broker plays the role of Supplier to the Customer. 


- a three-piece chain, where the Broker deals with the Customer and 
the Supplier but not with any other Broker. 


- a longer chain, with one or more interbroker operations. 


Minimal Supply Chain: 


+-------- + $as$SS55SS=455 + 
|Customer| <=====> | Broker | 
+-------- + | (as Supplier) | 
e a + 
3-piece Supply Chain: 
fiara + #+-sSsSs5= + pHa + 
|Customer| <===> | Broker | <===> |Supplier| 
+-------- + +-------- + +-------- + 
Longer Supply Chain: 
+-------- + +-------- + +-------- + +-------- + 
| Customer | <===> Broker | <=> | Broker <===> |Supplier| 
+-------- + +-------- + +-------- + +-------- + 


Figure 8 Supply Chains 
5.1.1. Minimal Supply Chains 


As discussed in the GAIA Reference Model, a GAIA transaction is 
composed of a number of actions, such as search, order, and delivery. 
Each transaction is initiated by the Customer who makes a request to 
the Broker. In the event that the Broker is able to fulfil the 
request, the transaction involves no other actors. 


In this simple case, the GAIA transaction involves the Customer and 
the Broker. The only protocol which needs to be standardised is that 
between the Customer and the Broker. This is specified in the GAIA 
Standard Minimal profile below. 


5.1.2. Longer Supply Chains 


In the event that the Broker is not able to fulfil a request, the 
action may be propagated on to other Brokers, with the original 
Broker playing the Customer role. Each of these Brokers may in turn 
propagate the request if they cannot fulfil it. 


Eventually, if the action is successful, a Supplier will be found who 


can fulfil the request. The supply chain is thus made up a single 
Customer, one or more Suppliers, and one or more Brokers. 
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In order to propagate an action from one Broker to another, a 
standardised communication protocol must be defined for broker-broker 
interaction. This is specified in the Basic profile, below. This 
profile is based on CORBA. 


Supplier and Brokers, however, are not obliged to support the Basic 
profile of the GAIA Standard. They may instead use another, more 
traditional, protocol such as 239.50 for discovery, or ISO ILL for 
ordering. The Extension Modules to the GAIA Standard specify the 
profiles to be used for various brokerage functions. 


5.2. Introduction to the GAIA Standard Profiles and Modules 
The profiles specified are 


- The Minimal profile, which is the very least to which a GAIA Broker 
must conform 

- The Basic Profile, which allows inter-broker communication 

- A number of Extension Modules, which allow the Broker to provide 
various services, and to interoperate with Suppliers, Brokers and 
Customers using protocols specified in the modules 

- A set of Interface Modules, that defines which particular 
Functional Unit CORBA interfaces are supported by the Broker 


Each Broker must conform at least to the Minimal profile to provide a 
web-based user interface. In addition, to take part in inter-broker 
communications, the Basic profile is recommended. For interaction 
with non-CORBA-aware entities, and for the use of advanced services, 
there are other modules of the standard to which the Broker may 
conform. These are denoted "Extension Modules", and they 
characterise the protocols and standards in a particular area of 
functionality. A Broker can choose an appropriate set of Extension 
Modules to conform to according to the functionality it wishes to 
achieve. 


The GAIA Standard specifies all interfaces between FUM and FUs for 
the GAIA Broker. However, it would be too much to require every 
Broker to implement all of them. The GAIA Standard decomposes all 
interfaces into a number of Interface Modules. A Broker can choose a 
subset of Interface Modules that are more important in its area of 
operation, and implement interfaces defined in these modules. These 
interfaces are important only inside the broker system and do not 
play any role in communication with other GAIA actors. However, a 
declaration of supported interfaces is important for the 
administrator to find the areas in which the functionality of the 
Broker can be extended by attaching GAIA-conformant FUs. 
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5.3. Minimal Profile 


The minimum functionality that a Broker must support will allow it to 
provide services to the Customer as a part of a minimal chain. In 
this case, what is required of the Broker is simply a user interface 
for the Customer. Any further operations take place within the 
Broker, and so do not come within the scope of the standard. 


The Minimal profile requires the Broker to implement a user interface 
based on the HTTP 1.1 protocol, defined in RFC 2068 [3], and HTML 
2.0, defined in RFC 1866 [4]. It means that a Customer should be 
able to access the basic functionality of the GAIA Broker by using a 
HTTP 1.1 and HTML 2.0 conformant web-browser. 


It should be possible for Customers to locate a GAIA Broker. Thus a 
GAIA Broker should be registered in a Directory Service using a 
schema specified in the GAIA Standard [1]. 


4+------------------------------------------------- + 
| Minimal Profile | 
4+------------------------ 4+------------------------ + 
Customer HTTP 1.1 (server), 
HTML 2.0 
4+------------------------ 4+------------------------ + 
5.4. Basic Profile 


While the minimal functionality is sufficient to allow a Broker to 
function, an important aspect of any GAIA Broker functionality is 
dealing with other Brokers. The goal of the Basic profile is to 
achieve federation between Brokers. Every GAIA Broker can use the 
service of other GAIA Brokers in order to fulfil a request of a 
Customer. That Broker in turn can use the service of the third GAIA 


Broker. So every request can be chained by several Brokers. This 
extends the abilities of every GAIA action (Search, Locate, Order, 
etc.). Chained transactions are particularly important in the 


discovery phase of a transaction, where a Broker unable to fulfil a 
particular information requirement passes on the search to another 
Broker. 


The Basic profile requires the Broker to implement the GAIA Customer 
interface defined in terms of CORBA. This interface is described in 


more detail in Section 4.2 above. The Basic profile also requires 
the Broker to implement interface requestor procedures, i.e. to be 
able to connect to the Customer interfaces of other Brokers. The ORB 


used by the Broker should be conformant to the CORBA 2.0 
specification [2] and use IIOP protocol for inter-ORB communications 
[2]. 
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A full specification of the GAIA Customer interface is presented in 
the GAIA Standard [1]. 


A GAIA Broker should be able to find other Brokers and Suppliers. It 
should also allow other participants to find it. Thus a GAIA Broker 
should support a directory service. The Basic profile includes a 
directory access protocol for this purpose. The actual choice of 
protocol is not standardised, because the choice does not influence 
the success of the Broker’s inter-operation with other Brokers. The 
directory schema, which should be used, is specified in the GAIA 
Standard. 


The Basic profile suggested for a Broker to allow it to interoperate 
with other GAIA Brokers is as follows. 


GAIA Customer interface/IIOP (server) 


Customer | 
GAIA Customer interface/IIOP (client) | 


| 
| Search and Locate 
| (Discovery) 
Order GAIA Customer interface/IIOP (client) 
Directory Some directory access protocol, 
| | such as LDAP | 
4+------------------------ 4+--------------------------------------- + 


Extension Modules 


In order to allow Brokers to interoperate with other Brokers that do 
not support the Basic profile, and to allow Brokers to deal with 
Suppliers and Customers who are not CORBA-aware, as well as to allow 
delivery of items and data streams via the Broker, other open 
technologies are suggested as extensions to the Basic and Minimal 
profiles. These technologies reflect the results of the technology 
evaluation carried out as part of the project GAIA. 


The extra protocols are grouped into Extension Modules. Support of 
these Extension Modules is optional. A Broker can choose an 
appropriate set of Extension Modules to conform to according to the 
functionality it wishes to achieve. There is one Extension Module 
for each of the functional areas which are not covered by the Basic 
and Minimal Profiles, and also one Extension Module for each of the 
existing areas (Customer, Discovery, and Order) to allow the use of 
protocols other than GAIA abstract primitives. 
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The following Extension Modules are defined. 


- Discovery Extension Module 

- Order Extension Module 

- Discrete Delivery Extension Module 
- Stream Delivery Extension Module 

—- Security Extension Module 

- Payment Extension Module 

- Alerting Extension Module 

- Customer Discovery Extension Module 


5.5.1. Discovery Extension Module 


The Discovery Extension Module specifies the technologies to be used 
in searching for and locating products and services. 


This Extension Module requires the Broker to support the client part 
of the 239.50 protocol, as defined in [5]. The following subset of 


the protocol is required: 


- Init, Search, and Present services 
- GRS-1 record syntax 


239.50 protocol PDUs should be carried using TCP/IP network 


protocols. 
$o------------------- === ++ + 
| Discovery Extension Module | 
$------------------------ $o------------------------ + 
| Searching, | 239.50 (client) 

| Locating | | 
Pn E +------------------------ + 


5.5.2. Order Extension Module 


The Order Extension Module specifies the protocols to be used to 
order products and services from a Supplier. 


This Extension Module requires the Broker to support all mandatory 
services of the client part of the ISO ILL protocol [6]. Basic 
conformance criteria should be adhered to. ISO ILL protocol PDUs 
should be carried using TCP/IP network protocols. 
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Pees Ss eee SS SRS SS eae SS eS Ha See SaaS + 

| Order Extension Module | 

Pe a E PSUS A S + 

| Order | ISO ILL (client) | 

E A $------------------------ + 
5.5.3. Discrete Delivery Extension Module 


The Discrete Delivery Extension Module specifies the protocols and 
standards to be used for the delivery of on-line products and 
services to the Customer. There are two delivery scenarios 
considered 


- Direct Supplier to Customer delivery 
The delivery may be a single-step operation, with the Supplier 
supplying his product directly to the Customer without the 
involvement of any Broker in the delivery process. The Broker may 
have acted to refer the Customer to the Supplier. In this case, 
where the Broker is not involved in delivery, the Discrete Delivery 
Extension Module does not apply. 


- Delivery over a supply chain with one or more Brokers involved 
In the event of the Broker being the central link in a supply chain 
of the form of Supplier-Broker-Customer, the Broker will use the 
protocols specified in the Discrete Delivery Extension Module to 
receive the product from the Supplier, and to provide the product 
to the Customer. 


The Discrete Delivery Extension Module requires the Broker to provide 
both FTP client and FTP server functionality [7], to allow the Broker 


to receive and to transmit files using FTP. 


The Discrete Delivery Extension Module also requires the GAIA Broker 


to be able to accept and to generate e-mail messages. The e-mail 
protocol specified is Internet e-mail, based on the SMTP protocol [8] 
and mail data formats specified in RFC 822 [9]. This protocol is 
sufficient for the creation, transmission, and management of textual 
e-mail messages. However, for the transmission of data files of 


various types, extensions to the SMTP/RFC822 protocols are required. 
The mail extensions specified by the Discrete Delivery Extension 
Module are based on MIME (Multipurpose Internet Mail Extensions), 
defined in RFCs 2045-2049 [10]. Thus a GAIA Broker must be able to 
send and receive "simple" SMTP/RFC822 mail, and also be able to deal 
with RFC 2045-2049 MIME mail extensions. 


For electronic document delivery the Discrete Delivery Extension 
Module requires the support of GEDI version 3.0. 
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PRS SSS aaa Sse SSeS Sse SSeS Sa Se Sa eS sae ess + 
| Discrete Delivery Extension Module | 
Garabedian tax bet anion ahaa po ene ota PSS - SSS esos SSS eS SS Sas e SSeS + 
| FTP profile | FTP (client+server) 
| Email profile | Internet e-mail [SMTP,RFC822] | 
| | (receiver+sender), | 
| | MIME | 
| Document delivery | GEDI version 3.0 | 
TesSensnre erea Possess O E + 

5.5.4. Stream Delivery Extension Module 


This Extension Module is intended to support real-time delivery of 
multimedia by the GAIA Broker. 


Several scenarios of stream delivery are considered. A stream can be 
delivered 


directly from a Supplier to a Customer 
The Broker does not take part in the stream delivery process; this 
scenario is out of scope of this standard. 


from a Supplier to a Customer via a Broker 

The Broker can add value to the stream delivery process by 
implementing cache algorithms, mixing streams, branching one stream 
to several Customers, etc. 


from a Broker to a Customer 

The Broker can keep a small amount of multimedia data (e.g. audio 
examples) in its own database and deliver it to a Customer upon 
request. 


The Stream Delivery Extension Module is recommended to be implemented 
by a Broker in order to provide the last two scenarios of real-time 
multimedia delivery. 


The Stream Delivery Extension Module requires the Broker to support 
the following technologies: 


— Compression 


MPEG-2 Audio Layer 3, specified in ISO/IEC 13818-3 [11]. Only 
support of constrained parameter streams (CSPS) is required. 


Data transfer protocol 

RIP protocol over UDP/IP, defined in RFC 1889 [12] (both client and 
server parts). It is recommended that the full behaviour of an RTP 
application service entity ("translator" or "mixer") is supported 
but it is not required. 
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- Mapping 
RTP payload format for MPEG Audio (MPA), defined in RFC 2250 [13]. 


- Session control protocol 
RTCP, specified in RFC 1889 [12]. 


This profile provides delivery of high quality audio over networks 
with non-guaranteed quality of service such as the Internet. 


+---------------------------------------------------- + 
| Stream Delivery Extension Module | 

+-------------------------- +------------------------- + 
| Compression | MPEG-2 Audio Layer 3 

| Data transfer | RTP (client+server) 

| Mapping | RFC 2250 

| Session control protocol | RTCP 

+------------------------ +------------------------- + 
5. Security Extension Module 


The basic security services required for GAIA are 


- Authentication of users, remote servers (both as entity 
authentication and as bilateral peer-to-peer authentication), 
senders and receivers in network transactions, as well as the 
authentication of documents. Authentication is required for three 
Situations: authentication at the user workstation when starting 
the session, authentication in a local environment (client/server 
authentication) and authentication in a global, open network 
(Internet). 


- Confidentiality and integrity of all resources transferred over the 
network or handled locally at application servers and user 
workstations. 


- Control of access to services and resources. 


- Non-repudiation of transactions, participants, and sensitive 
documents. 


This module allows a Broker to secure communications with other 
participants. It provides channel security, authentication, and 


certificate exchange. 


The Security Extension Module specifies the following protocols and 
algorithms: 


- Privacy, integrity, non-repudiation 
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SSL v3.0 protocol, defined in [14]. 
PKCS #7, defined in [15]. 


- Remote, client/server authentication 
GSS v5, specified in RFC 1508 [16]. 


— Certification services 
PKIX certification protocol, specified in [17]. 


Fn nn nn a a a aT a + 
| Security Extension Module 

fH sss SSSR SSS ssa A AEN A + 
| Privacy, integrity, non-repudiation | SSL v 3.0, PKCS #7 | 
| Remote, client/server authentication | GSS v5 

| Certification services | PKIX certification | 
| | protocol | 
Fann EE T T EES forhi nan + 


5.5.6. Payment Extension Module 


This module allows a Broker to perform electronic payment operations 
with Customers, Suppliers, and other Brokers. Such operations may take 
place at any stage during a GAIA transaction, during a Search, Locate, 
Order, or Deliver Action. 


The GAIA Standard does not specify the tariffing or charging model to 
be used by a Broker; this is considered to be an internal matter. 
However, when a bill has been agreed, payment must take place in a 
secure and mutually acceptable manner. The payment procedure specified 
in the GAIA Standard makes use of the SET specification. 


The Payment Extension Module requires a Broker to support SET v1.0 
merchant’s server and SET certification protocol, specified in [18]. 


| Payment Extension Module 
$——--- 5-5 t----- 5 E T + 
| Payment | SET v 1.0 : | 
| | 1) CA server for banks | 
) Cardholder wallet 
3) Merchant Server 

| 4) Payment Gateway server | 
+---------- E E N t----- E E E A ETE E + 
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5.5.7. Alerting Extension Module 


The Alerting Extension Module specifies the protocols to notify 
Customers about changes that can be interesting for them. 


This Extension Module requires the support of the following 
technologies: 


- Internet e-mail, based on SMTP protocol [8], 

and mail data formats specified in RFC 822 [9]. 

The Broker should be able to generate and send e-mail messages. 
-— SMS (Short Message Service), specified in [19]. 


4+--------------------------------- - - - = + 

| Alerting Extension Module 

+----------- 4+----------------------------------------- + 

| Alerting | Internet e-mail [SMTP,RFC822] (sender), | 

| | sMs | 

+----------- 4+----------------------------------------- + 
5.5.8. Customer Discovery Extension Module 


The Customer Discovery Extension Module allows 239.50 clients to use 
the service of the GAIA Broker. 


This Extension Module requires the Broker to support the server part 
of the 239.50 protocol, as defined in [5]. The following subset of 


the protocol is required: 


- Init, Search, and Present services 
- GRS-1 record syntax 


Z39.50 protocol PDUs should be carried using TCP/IP network 


protocols. 

HS a See ee a a ee ee eee + 
| Discovery Extension Module 

Sa a er et | Aina onan arta Faectema daa teieetcmetaar abet + 
| Searching, | 239.50 (server) 

| Locating | | 
+--------------------- A T E A + 


5.6. Interface Modules 


For the purpose of conformance, all interfaces between FUMs and FUs, 
specified by the GAIA Standard, are grouped into GAIA Interface 
Modules. These modules are recommended to be supported by a GAIA 
Broker, but they are not mandatory. A Broker can choose a subset of 
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Interface Modules that are more important in its area of operation, 
and implement interfaces defined in these modules. 


A full specification of the Functional Unit interfaces is presented 
in the GAIA Standard [1]. 


The following table defines Interface Modules and specifies which 
interfaces have to be supported in each of them. 


tan sa + 
| Interface Module | Interfaces that are required to be | 
| | supported in this module 
sar a aan SSS ceca remem nm a ge a + 
| Search | Search FU interface 
| Locate | Locate FU interface 
Order Order FU interface 
| Discrete Delivery | Discrete Delivery FU interface 
| Stream Delivery | Stream Delivery FU interface | 
| Customer | Customer FU interface 
| Alerting | Alerting FU interface 
| Directory Services | Directory Services FU interface | 
Authentication Authentication FU interface 
Payment Payment FU interface 
pine a ee + 
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7. Security Considerations 


Security issues related to the electronic brokerage are discussed in 
Sections 2.1.4, 2.3 and 5.4.5. 
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Full Copyright Statement 
Copyright (C) The Internet Society (1999). All Rights Reserved. 


This document and translations of it may be copied and furnished to 
others, and derivative works that comment on or otherwise explain it 
or assist in its implementation may be prepared, copied, published 
and distributed, in whole or in part, without restriction of any 
kind, provided that the above copyright notice and this paragraph are 
included on all such copies and derivative works. However, this 
document itself may not be modified in any way, such as by removing 
the copyright notice or references to the Internet Society or other 
Internet organizations, except as needed for the purpose of 
developing Internet standards in which case the procedures for 
copyrights defined in the Internet Standards process must be 
followed, or as required to translate it into languages other than 
English. 


The limited permissions granted above are perpetual and will not be 
revoked by the Internet Society or its successors or assigns. 


This document and the information contained herein is provided on an 
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 
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